home *** CD-ROM | disk | FTP | other *** search
/ The Arsenal Files 4 / The Arsenal Files 4 (Arsenal Computer).ISO / synchron / syncqnet.doc < prev    next >
Encoding:
Text File  |  1995-03-23  |  22.2 KB  |  574 lines
  1. Synchronet QWK Network Extenstions 03/23/95
  2. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  3.  
  4. This document is intended for developers of QWK off-line readers or mail doors
  5. for non-Synchronet BBS packages.
  6.  
  7. Synchronet multinode BBS software (by Digital Dynamics) has never had a QWK
  8. door written for it, because it has had extensive internal QWK off-line reader
  9. and network support since version 1 (1992). Since QWK networking is such an
  10. integrated component of Synchronet, it is extremely easy to setup and maintain
  11. in comparison to other network technologies (Fido, PostLink, Internet, etc.)
  12. which are also internally supported, but not as easy to setup for novice
  13. sysops.
  14.  
  15. Through our (Digital Dynamics) own extensions to the QWKnet pseudo-standard,
  16. we have filled many of the gaps that left QWK behind when it came to more
  17. advanced network needs (most notably, routed NetMail).
  18.  
  19. Not all of the information in this document will be relevant to your
  20. development, but we would much rather give too much information, than not
  21. enough. If other BBS program/mail-door authors choose not to implement this
  22. standard, it WON'T be because we didn't supply enough information!
  23.  
  24. Our QWKnet extensions are an evolving entity and we're definitely open
  25. to suggestions for future enhancements/compatibilty issues. See the end of
  26. this document for ways to contact Digital Dynamics. We encourage other
  27. developers to contact us directly for questions or notification of
  28. compatibility or intended compatibility between their product and ours.
  29.  
  30. Basics
  31. ------
  32. Synchronet has an entirely separate message area specifically designed for
  33. local E-mail and NetMail (as opposed to public message areas or "echoes").
  34. This "e-mail" message area is always conference number 0 in a QWK or REP
  35. packet. All non-zero conferences are sub-boards (AKA "Echoes", "SIGs",
  36. "Forums", etc).
  37.  
  38. QWK IDs (AKA BBSID) consist of between two and eight valid DOS characters and
  39. the first character must be alphabetic. QWK IDs must not contain the '@'
  40. character. It is extremely beneficial if all QWK IDs are unique in a given
  41. network of systems. QWK IDs that do not match this format may work for basic
  42. QWKnet functions, but many features may not work. QWK IDs are always considered
  43. case insensitive. The strings "SYSOP" and "NETMAIL" must are not valid QWK IDs.
  44.  
  45. A QWKnet node on a Synchronet BBS must be created specifically for QWK
  46. networking. This is done by using the node's QWK ID as the user name on the
  47. BBS and the sysop must give the account the 'Q' restriction. This restriction
  48. allows the uploaded REP packets to come from any user name (AKA Net Status)
  49. and automatically eliminates non-QWK networked sub-boards from the QWK packets.
  50. The 'Q' restriction causes the QWK menu to immediately come up at logon
  51. (rather than the normal "user" logon procedure), taglines are added to
  52. locally created messages being exported to REP packets, as well as other
  53. behavior differences from normal "user" accounts. Synchronet creates a
  54. NETFLAGS.DAT file for 'Q' restricted accounts that haven't disabled CONTROL
  55. files in the QWK packets, though Synchronet itself does not ever use the
  56. NETFLAGS.DAT - it's created for compatibility with non-Synchronet QWKnet nodes.
  57.  
  58. Conference Numbers
  59. ------------------
  60. When calling a Synchronet BBS for QWK packets, conference numbers will start
  61. at 0 (for E-mail) and then jump to 1001 or 2001 or a similar number.
  62. The thousands place represents the message Group number and the hundreds place
  63. represents the Sub-board number within that group. Conference numbers are
  64. not necessarily consequetive, though they are (at this time) always sequential.
  65. The CONTROL.DAT file will contain a list of all the conferences (and numbers)
  66. the current account has access to. Here is an example CONTROL.DAT:
  67.  
  68. --------------------------------[ Cut Here ]-----------------------------------
  69. Vertrauen
  70. Fullerton, CA
  71. 714-529-9525
  72. Digital Man, Sysop
  73. 0000,VERT
  74. 02-28-1995,03:22:02
  75. Tmbbs
  76.  
  77. 0
  78. 0
  79. 88
  80. 0
  81. E-mail
  82. 1001
  83. Notices
  84. 1002
  85. General
  86. 1003
  87. Software
  88. 1004
  89. Hardware
  90. 1005
  91. Progrmming
  92. 1006
  93. R.F.I.M.
  94. 1007
  95. Opinion
  96. 2001
  97. DOVE-Net
  98. 2002
  99. Ads
  100. 2003
  101. Entertain
  102. 2004
  103. Debate
  104. 2005
  105. Computers
  106. 2006
  107. Programmin
  108. 2007
  109. Synchronet
  110. 2008
  111. SBBS Sysop
  112. 2009
  113. Domain Ent
  114. 2010
  115. SyncData
  116. 3001
  117. FidoNet
  118. 3002
  119. Musicians
  120. 3003
  121. prog rock
  122. 3004
  123. Monte Pyth
  124. 3005
  125. Gaming
  126. 3006
  127. Flight-Sim
  128. HELLO
  129. BBSNEWS
  130. GOODBYE
  131. --------------------------------[ Cut Here ]-----------------------------------
  132.  
  133. When a Synchronet system calls a QWKnet hub, it can use any conference number
  134. scheme the hub system is using (max conference number 65535), but NetMail is
  135. always assumed to be sent and received from conference number 0.
  136.  
  137. REP Packet Control Messages
  138. ---------------------------
  139. When calling a Synchronet BBS, the following control messages are supported
  140. when included in an uploaded REP packet:
  141.  
  142. Subj: DROP [conf#]
  143. Note: Drop current conference (or specified conference #) from future packets
  144.  
  145. Subj: ADD [ptr | -msgs | mm/dd/yy]
  146. Note: Add current conference to future packets and optionally set message ptr
  147.  
  148. Subj: ADD [YOURS] [ptr | -msgs | mm/dd/yy]
  149. Note: Add current conference to future packets and optionally set message ptr
  150.       If "YOURS" is specified, only mail addressed to you will be packed for
  151.       this conference. Not applicable for QWKnet node accounts.
  152.  
  153. Subj: YOURS [ptr | -msgs | mm/dd/yy]
  154. Note: Same as "ADD YOURS"
  155.  
  156. Subj: RESET [ptr | -msgs | mm/dd/yy]
  157. Note: Set message pointer for current conference, - indicates offset from last
  158.  
  159. Subj: RESETALL [ptr | -msgs | mm/dd/yy]
  160. Note: Set message pointers for all conferences
  161.  
  162. Subj: FREQ <filename>
  163. Note: File Request from file transfer database (not attachments)
  164.  
  165. Subj: FILES [ON | OFF | mm/dd/yy]
  166. Note: Include files list in packet and/or specify new-scan date
  167.  
  168. Subj: ATTACH [ON | OFF]
  169. Note: Include file attachments in packet automatically (e-mail only)
  170.  
  171. Subj: MAIL [ALL | ON | OFF]
  172. Note: Include private mail-box (ALL includes previously read mail)
  173.  
  174. Subj: DELMAIL [ON | OFF]
  175. Note: Automatically delete mail-box after successful packet download
  176.  
  177. Subj: CTRL-A [KEEP | EXPAND | STRIP]
  178. Note: Ctrl-A color/attribute codes - leave-in, expand to ANSI, or remove
  179.  
  180. Subj: NDX [ON | OFF]
  181. Note: Include index (.NDX) files (not necessary for Synchronet QWKnet)
  182.  
  183. Subj: CONTROL [ON | OFF]
  184. Note: Include control files (DOOR.ID, CONTROL.DAT, NETFLAGS.DAT, etc)
  185.  
  186. Subj: VIA [ON | OFF]
  187. Note: Include messge path (@VIA) line in messages
  188.  
  189. Subj: TZ [ON | OFF]
  190. Note: Include time zone (@TZ) line in messages
  191.  
  192. Example DOOR.ID created by Synchronet v2.11:
  193.  
  194. --------------------------------[ Cut Here ]-----------------------------------
  195. DOOR = Synchronet
  196. VERSION = 2.11
  197. SYSTEM = Synchronet v2.11
  198. CONTROLNAME = SBBS
  199. CONTROLTYPE = ADD
  200. CONTROLTYPE = DROP
  201. CONTROLTYPE = YOURS
  202. CONTROLTYPE = RESET
  203. CONTROLTYPE = RESETALL
  204. CONTROLTYPE = FILES
  205. CONTROLTYPE = ATTACH
  206. CONTROLTYPE = OWN
  207. CONTROLTYPE = MAIL
  208. CONTROLTYPE = DELMAIL
  209. CONTROLTYPE = CTRL-A
  210. CONTROLTYPE = FREQ
  211. CONTROLTYPE = NDX
  212. CONTROLTYPE = TZ
  213. CONTROLTYPE = VIA
  214. CONTROLTYPE = CONTROL
  215. MIXEDCASE = YES
  216. --------------------------------[ Cut Here ]-----------------------------------
  217.  
  218. Transferring Files Between Nodes and Hubs
  219. -----------------------------------------
  220. Any non-QWK related files included in a QWKnet REP packet uploaded to a
  221. Synchronet BBS (or QWK packets received from a QWKnet hub) will be
  222. automatically moved into the DATA\QNET\<QWKID.IN> directory (where QWKID is the
  223. QWK ID of the node or hub that sent the file) and the sysop will be notified of
  224. the received file.
  225.  
  226. If a Synchronet sysop wishes to send a QWKnet node or hub a file, he need only
  227. create the directory DATA\QNET\<QWKID.OUT> (where QWKID is the QWK ID of the
  228. destination node) and copy the file(s) into this directory. The next time this
  229. node calls and downloads a REP packet (or a QWK is packed for the hub), this
  230. file will be archived in the packet automatically and then deleted from the
  231. .OUT directory. This is NOT the same as FREQing (File Requesting) a file. It is
  232. just a simple means of transferring files between QWKnet nodes and hubs.
  233.  
  234. NetMail
  235. -------
  236. When downloading a QWKnet packet from a Synchronet BBS, any e-mail (conf #0)
  237. waiting for the QWKnet node account will be automatically included in the
  238. packet. If the TO: name is the node's QWK ID or the word "SYSOP" (not case
  239. sensitive), the NetMail should be assumed to be intended for the Sysop.
  240. Otherwise if the TO: name is not "NETMAIL" (not case sensitive), then it is a
  241. single hop NetMail message intended for a user on the node's system going by
  242. the TO: name. The same holds true for REP packets sent to hubs containing
  243. messages in conf #0.
  244.  
  245. Routed NetMail
  246. --------------
  247. Messages sent to "NETMAIL" (not case sensitve) in conference number 0 are
  248. intended for another system that the current system unpacking the packet
  249. must forward the message to. The destination user name and address will be
  250. on the VERY first line of the message text in the following format:
  251. "name@addr"
  252. Where "name" is the full user name (25 chars max) and "addr" is EITHER the
  253. destination node's QWK ID or the complete routing address. Complete routing
  254. addresses are stored as: "NEXTID/.../DESTID", where NEXTID is the QWK ID of
  255. next system in the link and DESTID is the inteded destination's QWK ID. The
  256. "..." portion of the above routed address designates a variable number of
  257. QWK IDs to pass through before reaching the DESTID.
  258.  
  259. Synchronet, automatically expands QWK ID's to complete routing addresses
  260. whenever possible (when the path is known), so expect to find the complete
  261. routing address more often than just the destination QWK ID.
  262.  
  263. When a system discovers a routed NetMail message in a QWK or REP packet it
  264. needs to determine if the next hop is the destination node, and if so, change
  265. the TO: field to the destination user name and eliminate the "user@addr"
  266. line from the message.
  267.  
  268. If the next hop is not the destination node, it needs to leave the TO: field
  269. as "NETMAIL" and remove itself and the next hop from the "addr" portion of
  270. the "user@addr" line before creating the QWK or REP packet for the next hop.
  271. After exporting the NetMail message sucessfully to QWK or REP, it should be
  272. deleted.
  273.  
  274. EchoMail
  275. --------
  276. So, you're probably asking yourself, how does Synchronet know how to expand
  277. a QWK ID into a complete routing address? Well, the @VIA: line is the key.
  278. Every mail message (EchoMail and NetMail) that has passed through at least one
  279. system to reach the current system will contain a special first line in the
  280. body text:
  281. "@VIA: QWKID/.../ORGID"
  282. Where QWKID is the ID of the system that sent the message to the system that
  283. created the QWK or REP packet being unpacked and ORGID is the originating
  284. system's QWK ID.
  285.  
  286. Mail that originates on a node or hub will not contain an @VIA: line when
  287. exported to nodes or hub that are directly connected to it. Only when THOSE
  288. systems then export the message again, is the @VIA: line added.
  289.  
  290. Synchronet parses the @VIA: line (if it exists) to automatically maintain
  291. a dynamic "route map" (filename DATA\QNET\ROUTE.DAT). Each line contains
  292. information about a QWKnet system that is not directly connected. The format
  293. (though not necessarily relevant to other BBS packages) is:
  294. "MM/DD/YY DESTID:QWKID/QWKID/QWKID/..."
  295. Where MM/DD/YY is the date the entry was last updated in the route file, DESTID
  296. is the QWK ID of the system which we are defining the routing, and QWKID/QWKID
  297. etc. are the QWK IDs of the systems necessary to reach DESTID.
  298.  
  299. Synchronet updates entries for existing DESTID, so if the routing changes,
  300. the route file changes automatically. Old entries (indicating no mail traffic
  301. from DESTID in X number of days) are automatically deleted. Synchronet uses 90
  302. days as maximum age to keep old route entries.
  303.  
  304. Synchronet comes with a utility (QWKNODES.EXE) that can be used to manually
  305. scan the existing message bases and create a ROUTE.DAT file (mentioned above),
  306. a USERS.DAT file (for automatically looking up user names on other systems),
  307. and a NODES.DAT file (not currently used by Synchronet, mainly for human
  308. consumption - finding a QWKnode near you!). The format of the USERS.DAT file
  309. is each line:
  310. "username                   DESTID    MM/DD/YY  (QWKID/.../DESTID)"
  311. Where username is the user's full name, DESTID is the QWK ID of the system
  312. the user is on (or last posted from), MM/DD/YY is the date the message was
  313. imported, and QWKID/.../ is the path to the DESTID (if not direct connection).
  314. The only parts Synchronet uses at this time are username and DESTID (ROUTE.DAT
  315. is used to expand to complete routing address if necessary).
  316.  
  317. When importing mail with an @VIA: line, Synchronet also checks to make
  318. sure that the current system's QWK ID is not present in the list of QWK IDs.
  319. If it is present, then the message is assumed to be an erroneous dupe loop and
  320. is ignored (not imported). This is called "circular path detection" and is
  321. caused by systems that accidentally hub off of more than one system in the
  322. same QWK network causing a message "loop".
  323.  
  324. @VIA: lines can be disabled on a Synchronet hub by sending a message to "SBBS"
  325. with a title of "VIA OFF".
  326.  
  327. Synchronet automatically disables @VIA: lines for hubs when "Ctrl-A Codes" are
  328. not set to "Leave-in" (this is done by the Synchronet sysop in SCFG), assuming
  329. this indicates the hub BBS is not a Synchronet system. So, if you're receiving
  330. @VIA: codes from a Synchronet BBS that is a node (not a hub) off of your
  331. system, expect to receive Synchronet Ctrl-A codes too! :) Synchronet Ctrl-A
  332. codes are ANSI equivalents (using a more simple escape sequence) defined as:
  333.  
  334. (All attribute codes are be preceeded by a Ctrl-A character - ASCII 1)
  335.  
  336.     Foreground  Background
  337. Black        K        0
  338. Red        R        1
  339. Green        G        2
  340. Yellow        Y        3
  341. Blue        B        4
  342. Magenta     M         5
  343. Cyan        C        6
  344. White        W        7
  345.  
  346. High        H    High Intensity
  347. Blink        I    Blinking
  348. Normal      N   No Special Attributes
  349. Pause       P   Insert a Pause Prompt into message
  350. CLS         L   Insert a Form Feed into message
  351.  
  352.  
  353. Time Zone
  354. ---------
  355. Another missing element of the QWK format is time zone information. Synchronet
  356. offers time zone information in QWK messages by adding an @TZ: line before the
  357. message body (below "name@addr" and "@VIA:" lines if they exist). The time
  358. zone specified is of the originating system. The format is:
  359. "@TZ: xxxx"
  360. Where xxxx are four hex digits (16-bit signed value). The value of the hex
  361. digits is defined in the SMB (Synchronet Message Base) specification, but for
  362. your convenience, we have included it here:
  363.  
  364.     If the zone is in the range -720 to +720, it represents the
  365.     number of minutes east or west of UT. Values in this range
  366.     should only be used for time zones not otherwise represented
  367.     here.
  368.  
  369.     If the zone is greater than 720 or less than -720, then the
  370.     following bits have special meaning:
  371.  
  372.     (1<<12)     // Non-US time zone    (east of UT)
  373.     (1<<13)     // Non-US time zone    (west of UT)
  374.     (1<<14)     // U.S. time zone
  375.     (1<<15)     // Daylight savings
  376.  
  377.     The lower 12 bits (0 through 11) contain the number of minutes
  378.     east or west of UT (not accounting for daylight savings).
  379.  
  380.     If the time zone is one specified in the U.S. Uniform Time Act,
  381.     the following values represent the zone:
  382.  
  383.     AST 0x40F0    // Atlantic        (-04:00)
  384.     EST 0x412C    // Eastern        (-05:00)
  385.     CST 0x4168    // Central        (-06:00)
  386.     MST 0x41A4    // Mountain        (-07:00)
  387.     PST 0x41E0    // Pacific        (-08:00)
  388.     YST 0x421C    // Yukon        (-09:00)
  389.     HST 0x4258    // Hawaii/Alaska    (-10:00)
  390.     BST 0x4294    // Bering        (-11:00)
  391.  
  392.     With bit 15 set, the following values represent the same zone
  393.     with the presence of daylight savings:
  394.  
  395.     ADT 0xC0F0    // Atlantic        (-03:00)
  396.     EDT 0xC12C    // Eastern        (-04:00)
  397.     CDT 0xC168    // Central        (-05:00)
  398.     MDT 0xC1A4    // Mountain        (-06:00)
  399.     PDT 0xC1E0    // Pacific        (-07:00)
  400.     YDT 0xC21C    // Yukon        (-08:00)
  401.     HDT 0xC258    // Hawaii/Alaska    (-09:00)
  402.     BDT 0xC294    // Bering        (-10:00)
  403.  
  404.     The following non-standard time zone specifications may also be
  405.     used:
  406.  
  407.     MID 0x2294    // Midway        (-11:00)
  408.     VAN 0x21E0    // Vancouver        (-08:00)
  409.     EDM 0x21A4    // Edmonton        (-07:00)
  410.     WIN 0x2168    // Winnipeg        (-06:00)
  411.     BOG 0x212C    // Bogota        (-05:00)
  412.     CAR 0x20F0    // Caracas        (-04:00)
  413.     RIO 0x20B4    // Rio de Janeiro    (-03:00)
  414.     FER 0x2078    // Fernando de Noronha    (-02:00)
  415.     AZO 0x203C    // Azores        (-01:00)
  416.     LON 0x1000    // London        (+00:00)
  417.     BER 0x103C    // Berlin        (+01:00)
  418.     ATH 0x1078    // Athens        (+02:00)
  419.     MOS 0x10B4    // Moscow        (+03:00)
  420.     DUB 0x10F0    // Dubai        (+04:00)
  421.     KAB 0x110E    // Kabul        (+04:30)
  422.     KAR 0x112C    // Karachi        (+05:00)
  423.     BOM 0x114A    // Bombay        (+05:30)
  424.     KAT 0x1159    // Kathmandu        (+05:45)
  425.     DHA 0x1168    // Dhaka        (+06:00)
  426.     BAN 0x11A4    // Bangkok        (+07:00)
  427.     HON 0x11E0    // Hong Kong        (+08:00)
  428.     TOK 0x121C    // Tokyo        (+09:00)
  429.     SYD 0x1258    // Sydney        (+10:00)
  430.     NOU 0x1294    // Noumea        (+11:00)
  431.     WEL 0x12D0    // Wellington        (+12:00)
  432.  
  433. Examples
  434. --------
  435. Examples are usually helpful at understanding concepts, so we are going to
  436. use a real-life Synchronet extended QWK network (DOVE-Net) to deomonstrate
  437. how the above extensions work.
  438.  
  439. First, the network topology (abbreviated for this example):
  440.  
  441.        ┌────────────────┬─────────VERT──────────────────────┐
  442.        │            │           │            │
  443.   ┌──────PHOUSE─────┐      DOMAIN    NITEMOVE           ┌──────CENTURY──────┐
  444.   │       │        │               │           │    │       │
  445. CIRCLE7  FANTAIR  KRYSTAL      ┌──────TLOC──────┐    TALONBBS  VSS_BBS    PHOENIX
  446.                    │        │
  447.                  BLAZING       WILDHARE
  448.  
  449.  
  450. The ROUTE.DAT on VERT (master hub) for the above (in case you were curious):
  451.  
  452. --------------------------------[ Cut Here ]-----------------------------------
  453. 03/22/95 CIRCLE7:PHOUSE
  454. 03/22/95 TLOC:NITEMOVE
  455. 03/22/95 FANTAIR:PHOUSE
  456. 03/20/95 TALONBBS:CENTURY
  457. 03/17/95 BLAZING:NITEMOVE/TLOC
  458. 03/19/95 KRYSTAL:PHOUSE
  459. 03/19/95 VSS_BBS:CENTURY
  460. 03/20/95 PHOENIX:CENTURY
  461. 03/20/95 WILDHARE:NITEMOVE/TLOC
  462. --------------------------------[ Cut Here ]-----------------------------------
  463.  
  464. Mail originating on VERT would NOT contain an @VIA: line when sent to the
  465. following systems: PHOUSE, DOMAIN, NITEMOVE, and CENTURY. Mail originating on
  466. VERT would contain "@VIA: VERT" when sent to the systems: CIRCLE7, FANTAIR,
  467. KRYSTAL, TLOC, TALONBBS, VSS_BBS, and PHOENIX. Mail originating on VERT would
  468. contain "@VIA: NITEMOVE/VERT" went sent to the following systems: BLAZING and
  469. WILDHARE.
  470.  
  471. Mail originating on BLAZING would contain the following @VIA: lines when sent
  472. to the following systems:
  473.  
  474. TLOC:       <none>
  475. WILDHARE:  "@VIA: BLAZING"
  476. NITEMOVE:  "@VIA: BLAZING"
  477. VERT:       "@VIA: TLOC/BLAZING"
  478. DOMAIN:    "@VIA: NITEMOVE/TLOC/BLAZING"
  479. PHOUSE:    "@VIA: NITEMOVE/TLOC/BLAZING"
  480. CIRCLE7:   "@VIA: VERT/NITEMOVE/TLOC/BLAZING"
  481. FANTAIR:   "@VIA: VERT/NITEMOVE/TLOC/BLAZING"
  482. KRYSTAL:   "@VIA: VERT/NITEMOVE/TLOC/BLAZING"
  483. CENTURY:   "@VIA: NITEMOVE/TLOC/BLAZING"
  484. TALONBBS:  "@VIA: VERT/NITEMOVE/TLOC/BLAZING"
  485. VSS_BBS:   "@VIA: VERT/NITEMOVE/TLOC/BLAZING"
  486. PHOENIX:   "@VIA: VERT/NITEMOVE/TLOC/BLAZING"
  487.  
  488. Each of the above systems needs to have its own way of storing the QWK ID of
  489. the system the message last came from, so it can build the entire return
  490. address. Luckily, all of the above are Synchronet systems, which stores the
  491. complete route address in the SMB format message header. Different BBS packages
  492. will need different ways of storing the originating QWK ID or (preferrably)
  493. the complete route address (built from the above VIA path with the last hop
  494. QWK prepended to the address).
  495.  
  496. Using the above example, VERT would store the QWKnet address of mail
  497. originating from WILDHARE as "NITEMOVE/TLOC/WILDHARE". Synchronet does not
  498. actually store addresses in its local message bases using @VIA:. This is
  499. only used for extended the QWK format (which doesn't have a storage area for
  500. network addresses). The @VIA: portion of the message body is added and removed
  501. automatically from each message imported from or exported to QWK format (if
  502. applicable).
  503.  
  504. Using a Route Map
  505. -----------------
  506. If the BBS software or mail door uses a route map, (similar to the ROUTE.DAT
  507. that Synchronet uses), it should be able to insert routing information on
  508. the fly.
  509.  
  510. If for example, a user on VERT sent NetMail to a user on WILDHARE, Synchronet
  511. would look in the ROUTE.DAT and find an entry for WILDHARE and automatically
  512. expand the address from "user@WILDHARE" to "user@NITEMOVE/TLOC/WILDHARE".
  513. If a user on VERT were to send NetMail to "user@WILDHARE/BIGBBS", Synchronet
  514. would not even look for BIGBBS in the ROUTE.DAT (it only looks for the first
  515. hop in the routing), so it would still route the message properly to WILDHARE
  516. by changing the address to NITEMOVE/TLOC/WILDHARE/BIGBBS.
  517.  
  518. Each system that receives NetMail should compare the destination QWK ID to
  519. all the QWKnet nodes it feeds and the hubs it calls. If a match is found, it
  520. should ignore the routing information and send it directly (overriding the
  521. specified routing). Example, a user on TALONBBS sends NetMail to
  522. "user@CENTURY/VERT/PHOUSE/NITEMOVE" (an incorrect route, but valid as far as
  523. CENTURY knows) - it is possible that PHOUSE now feeds NITEMOVE and CENTURY does
  524. not yet know about it, so it leaves the route address intact and passes the
  525. message on to VERT. VERT sees that it feeds NITEMOVE directly, so it sends the
  526. mail directly (removing the routing information).
  527.  
  528. NetMail (again)
  529. ---------------
  530. Using the above example network topology, if a user were to send NetMail
  531. from BLAZING to a user on CIRCLE7:
  532.  
  533. REP sent from BLAZING to TLOC:
  534. Conf #0 - To: NETMAIL
  535.       1stLine: username@NITEMOVE/VERT/PHOUSE/CIRCLE7
  536.  
  537. REP sent from TLOC to NITEMOVE:
  538. Conf #0 - To: NETMAIL
  539.       1stLine: username@VERT/PHOUSE/CIRCLE7
  540.       2ndLine: @VIA: BLAZING
  541.  
  542. REP sent from NITEMOVE to VERT:
  543. Conf #0 - To: NETMAIL
  544.       1stLine: username@PHOUSE/CIRCLE7
  545.       2ndLine: @VIA: TLOC/BLAZING
  546.  
  547. QWK sent from VERT to PHOUSE:
  548. Conf #0 - To: NETMAIL
  549.       1stLine: username@CIRCLE7
  550.       2ndLine: @VIA: NITEMOVE/TLOC/BLAZING
  551.  
  552. QWK sent from PHOUSE to CIRCLE7:
  553. Conf #0 - To: username
  554.       1stLine: @VIA: VERT/NITEMOVE/TLOC/BLAZING
  555.  
  556.  
  557. Contact Information
  558. -------------------
  559. Digital Dynamics
  560. PO Box 501
  561. Yorba Linda, CA 92686
  562. 714-529-6328 Voice
  563. 714-529-9271 FAX
  564. 714-529-9525 BBS 14.4k V.32bis
  565. 714-529-9547 BBS 28.8k V.FC
  566. 714-529-9721 BBS 19.2k ZyXEL (reserved for networking)
  567. FidoNet:  1:103/705 V.32bis
  568.       1:103/706 V.FC
  569. RelayNet: 5115
  570. Internet: sysop@f705.n103.z1.fidonet.org
  571. DOVE-Net: sysop@vert
  572.  
  573. /* End of SYNCQNET.DOC */
  574.